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Abstract. The RODIN, and DEPLOY projects laid solid foundations 
for further theoretical, and practical (methodological and tooling) ad- 
vances with Event-B. Our current interest is the co-simulation of cyber- 
physical systems using Event-B. Using this approach we aim to simulate 
various features of the environment separately, in order to exercise de- 
ployable code. This paper has two contributions, the first is the extension 
of the code generation work of DEPLOY, where we add the ability to gen- 
erate code from Event-B state-machine diagrams. The second describes 
how we may use code, generated from state-machines, to simulate the 
environment, and simulate concurrently executing state-machines, in a 
single task. We show how we can instrument the code to guide the simu- 
lation, by controlling the relative rate that non-deterministic transitions 
are traversed in the simulation. 

1 Introduction 

This paper describes activities undertaken during the early part of the AD- 
VANCE [8] project. Building on the RODIN, and DEPLOY projects [9], we are 
working to better understand the issues arising in a development when modelling 
with Event-B, and animating with ProB, in tandem with a multi-simulation 
strategy. Some of DEPLOY's industrial partners were interested in the formal 
development of multi-tasking, embedded control systems. We developed an ap- 
proach for automatically generating code from Event-B models, for these types 
of systems [3] . In this paper we also present an extension to this work. 

Event-B uses set-theory, predicate logic and refinement to model discrete 
systems. The basic structural elements of Event-B models are contexts and ma- 
chines. Contexts describe the static aspects of a system, using sets, constants, 
and axioms. The contents of a Context can be made visible to a machine. Ma- 
chines describe the dynamic aspects of a system, in the form of state variables, 
and guarded events, which update state. Required properties are specified using 
the invariants clause. The invariants give rise to proof obligations. 

In the remainder of this section, we describe the Event-B representation of 
state-machines, and Tasking Event-B, our existing code-generation approach. 
We introduce a case study in Section [2] In Section [3] we describe the new code 
generation feature for Event-B state-machine diagrams. In Section|4]we describe 
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Fig. 1. EngMode State-machine 



how we use a single task, generated from state-machines, to simulate the envi- 
ronment and concurrently executing state-machines. We show how we guide the 
simulation, using additional guards on the transition implementations, to control 
the relative rate that non-deterministic transitions are traversed. We conclude 
with Section 03 

State-machine diagrams [T] can be added to a machine. Each contains an 
initial state, typically contains one or more transitions, one or more other states, 
and possibly a final state. A transition 'elaborates' one or more events; that is, a 
transition describes the atomic state updates that occur during the change from 
one state to the next. We use an example of an automotive engine stop-start 
controller, loosely based on [5], to illustrate our approach. The system aims to 
save fuel by switching the engine off when the car is stationary. Fig. [T] is an 
example of a state-machine diagram, EngMode. Initially the state-machine is in 
the ENG-OFF state, and may go the ENG-CRANKING state via transitions 
si or userStart, and so on. In the properties we define 'translation type' as 
Enumeration. The underlying Event-B model, uses a set-partition of the states, 
as shown below. The current state of the state-machine is recorded in a variable 
EngMode £ EngMode. ST AT ES , where EngMode.STATES is a partition of 
the states of the EngMode state-machine, 

partition ( EngMode. ST A TES , { ENG. STOPPING}, 

{ENG. CRANKING}, {ENG. RUNNING}, {ENG.OFF}) ^ 



1.1 Tasking Event-B 

Tasking Event-B |3l4j is an extension to Event-B; where Event-B elements are 
restricted to implementable types. If required we use decomposition |6|7j to sep- 
arate the system into sub-components. At an appropriate stage we introduce 
implementation specific constructs to guide code generation. These constructs 
are underpinned by Event-B operational semantics; Tasking Event-B introduces 
three main constructs:- AutoTask, Environ, and Shared Machines. AutoTask Ma- 
chines model controller tasks (in the implementation). Environ Machines model 



the environment, and Shared Machines provide a protected resource for sharing 
data between tasks. 

Tasks bodies are specified using the syntax shown in Fig. [2] We can use (;) 
sequence , (if-elsif-else) branching, (do) looping, and text output to the console. 



TaskBody ::= 
TaskBody ; TaskBody 
| if EventName 
(elseif EventName)* 

else EventName EventName ::= String 

| while EventName 

I output String VariableName VariableName ::= String 
Fig. 2. Task Body Syntax 



1.2 Translation of a Task Body 

To simplify the discussion, our example uses a single tasking approach. We will 
not consider here the issue of multi-tasking. We therefore need only to give a brief 
overview of AutoTask Machine translation, since it will not be synchronized with 
a Shared Machine. Given an event E = g — > a, we map action a to a program 
statement a', and guard g to a condition g 1 , if g exists. The guard should be T 
for events used in sequences, but may be any implementable predicate for use in 
branching and looping statements. An example translation of branching follows, 
where events e\ — gl — > a\ and e2 = gi — > a 2 , are used in the task body, 

if ei else e2 endif 

if g[ then a[ else d 2 end if; 

The branching construct of the task body contains events e\ and e2, and trans- 
lates to a branching construct in the program code. The guard g' 2 does not 
appear in the code, but to ensure that the modellers intentions are correctly 
implemented a proof obligation can be generated to ensure that 172 ^ - ><7i • The 
tool could be augmented to generate proof obligations automatically, to show 
that branch guards are disjoint and complete. 

2 The Automotive Stop-Start Model 

A typical approach to multi-tasking in hybrid systems, relies on a write-read- 
process protocol. The shared variable store, shown in Fig. [3j is used by the 
various modules; to write to, and then read from. In such a system, each task 
keeps a local copy of the parts of the state that it needs to deal with. In the 



write-read-process protocol, all tasks write to the store, all tasks then read from 
the store. Only when all tasks have updated their local copies of shared state, 
can processing take place. The task iterates these steps in a loop. In our tool we 
simulate the concurrent implementation using sequential code generated from a 
single AutoTask Machine. The deployable modules of Fig.[3]can be implemented 
in a multi-tasking environment if the execution order of the protocol is preserved. 

In our sequential simulation, we use a single AutoTask Machine, which con- 
tains both controller and environment state-machines; and define write and read 
behaviour in the machine's task-body construct. We have already seen the Stop- 
Start (SSE ) system's EngMode state-machine, in Fig. [I] In addition to this we 
have Clutch, Gear and Steering environment state-machines. There are three 
controller modules, the SSE Module that decides whether to issue stop or start 
commands based on the engine state, and values determined by the HMI Con- 
trols module. HMI Controls monitors the clutch, gear, and steering controls to 
see if automatic stop or start should be enabled. 
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Fig. 3. Overview of the Stop-Start Architecture 



2.1 The Task-body 

We have defined the state-machines of the system and we can now specify the 
10 between the modules via the shared variable store. The store contains a copy 
of all of the variables involved in 10 between modules. Each of the modules may 
send data and receive data from the variable store. If we take, as an example, the 
engine's 10, we output the engine state and speed to the shared variable store. 
All variables in the store are prefixed 'STO_', and variables in the engine module 
(other than state names) are prefixed 'ENG_', so the following event updates the 
shared variable store's copies of the engine state. Each state-machine has a send 
(write) and receive (read) event which has the state-machine name and send or 
recv as a suffix. 

Engsend = STO -EngMode := EngMode 

|| STO -EngineSpeed : = ENG JEngineSpeed 



2.2 Modelling Starting and Stopping the Engine 

The EngMode state-machine keeps track of the engine mode, i.e. off, running, 
cranking, or stopping. The engine is initially in the ENG.OFF state. We model 
the ultimate task of the SSE system, the automatic engine start, with the si 
event. This is enabled after receiving an engine start order from the Stop- 
Start Controller module (the SSE Module's SSEMode state-machine, introduced 
later). The si event follows, 

si = when EngMode = EN G -OFF A ENG. Start. Order = TRUE 
then EngMode := ENG. CRANKING 
end 

The predicate and action involving EngMode are generated automatically in the 
translation from the state-machine diagram. The guard with ENGStart-Order 
is added by the developer to indicate that the engine should enter the cranking 
state when a Start Order has been received. The engine may also be started 
manually, as modelled by the userStart event. When the engine is running at a 
sufficient rate s3 sets the engine state to ENG.RUNNING, 

s3 = when EngMode = ENG-CRANKING 

A Eng -EngineSpeed >= Eng -Idle Speed 
then EngMode := ENG.RUNNING 
end 

When the engine is running, it can be stopped automatically by the SSE module. 
The HMI.Controls module checks to see if it is in neutral gear, steering not-used, 
and clutch released. If it is, HMI.Stop.EnaT sets HMI.Stop.Ena to true. This 
is eventually passed to the SSEMode module via the shared store. 

HMI Stop -EnaT = 

when EMI -Gear = NEUTRAL A EMI Steer = NOT -USED 
A EMI .Clutch = RELEASED A HMI.ControlsSM = HMI .OPERATION 
then HMI. Stop. Ena := TRUE || HMI.Strt.Req := FALSE 
end 

Event t7 elaborates a transition of the SSE state-machine diagram, setting 
SSE Stop -Order and SSE Start -Order. This is copied to the variable store, 
and then read by the engine module. 

tl^ 

when SSEMode = SSE .OPERATION A SSE.Stop.Req = TRUE 
A SSE -EngMode = ENG -RUNNING A SSE Stop -Ena = TRUE 

then SSEMode := SSESTOPPING || SSE Stop -Order := TRUE 
|| SSE Start .Order := FALSE 

end 



^7 TASK BODY 
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Fig. 4. The Task Body Specification 

We specify the sequence of events in the Task Body in the 'usual' Tasking Event- 
B style, seen in Fig. [3] We have specified that send events occur before the read 
events. This is necessary to ensure the latest state is made available for the 
state-machine evaluation. The Task Body is periodic, and generates a loop in the 
implementation. The order of processing is as follows: 1) Initialisation of state. 2) 
Evaluate state-machines. 3) Send updated values to the variable store. 4) Read 
updated values from the variable store; then go to 2, and repeat. The sequence 
{4,2,3}, in the task body, corresponds to the read-process-write protocol, which 
follows initialisation (and initial sends to the variable store). Fig. [4] also shows the 
output clause, for text output to the console. The next section provides details 
of the translation to Ada code. 

3 Translating State-Machines to Ada Code 

To illustrate the translation process we show the Ada implementation, we have 
seen how state-machine states are modelled by an enumeration partition, and 
we use this in the implementation. The partition of Equation [l] is translated to 
the following Ada code. 

package StopStartOlb-Globals is 
type EngMode STATES is( 

ENG.STOPPING, ENG _ CRA NKING , 

ENG.RUNNING, ENG.OFF);... 

We create the package StopStart01b_Globals to store the global constants and 
types. The type EngModeSTATES is an enumeration of the state-machine 
states. Recall also, that we generate a state variable EngMode which is typed as 
EngMode € EngMode ST AT ES , to keep track of the state; it has the initial 
value Eng.OFF. We use the diagram and the initialisation event to generate the 
following code: 

EngMode : EngMode STATES := ENG -OFF; 



The main program invokes the state-machine implementations in a loop, once 
per cycle. Each state-machine diagram maps to a procedure. State-machine pro- 
cedures are called exactly once before the sends to, and reads, from the variable 
store. The evaluation of each state-machine procedure is independent of the 
other state-machines, since each keeps a local copy of the state, copied from the 
variable store. Each state-machine procedure has a state variable v, states u>i, 
and implemented actions a,. To each state-machine procedure, we add to a case 
statement, 

case v is when w\ => a\; 
when w 2 => a 2 ; ... 
when w n => null; 

Translation of our example gives rise to the following code, 

procedure EngModestateMachine is 
begin 

case EngMode is 

when ENG STOPPING => 

if ( ( ENG -EngineSpeed = 0)) then 

EngMode := ENG -OFF; - - s5 
elsif ((ENG Start. Order = true)) then 

EngMode := ENG -CRANKING; - - s6 
else null; 
end if; 

when ENG.CRANKING => 

if ((ENG -EngineSpeed = 0)) then 

EngMode := ENG -OFF; ~ ~ s2 
elsif ((ENG -EngineSpeed >= Eng -Idle Speed)) then 

EngMode := ENG -RUNNING; - - s3 
else null; 
end if; 

when ENG -RUNNING => . . . 
end case; 

end EngModestateMachine; 

We can see that each of the case's when statements contains a branching state- 
ment. This is because each state of the state-machine has at least two branches; 
a do-nothing transition, plus one or more outgoing transitions. The do-nothing 
transition is not explicitly shown on the diagram. A do-nothing transition can be 
added to each state, since adding a skip event is a valid refinement. It is imple- 
mented by the else null; branch. Other branches are translated from states with 



more than one outgoing transition. This may be seen in the ENGSTOPPING 
case in the example. The branch conditions are mapped from the guards of the 
events (s5 and s6) that elaborate the outgoing transitions. 

4 Manipulating State Machine Transitions 

The generated code from our example is compiled to an executable file and run. 
We have implementable code for the controller state-machines, and a simulation 
of the environment from the environment state-machines. When executing, we 
find that most of the state remains unexplored, and this is due to the non- 
determinism in the state-machines. This section identifies how we can guide a 
simulation, by reducing the non-determinism in the generated state-machine by 
modifying the branch conditions. 

For the controller state-machines, each state's outgoing transitions are dis- 
joint and complete; in other words, a transition is always taken in the simula- 
tion. However, in the environment, it is unlikely that the clutch changes state so 
frequently We do have the implicit do-nothing transition on environment state- 
machine states, but we need this to happen more often than the other transitions. 
We must have some control over the relative rate that non-deterministic tran- 
sitions are traversed in the simulation. As it stands, any outgoing transition is 
equally likely to occur. To solve this in the simulation, we introduce an enabling 
variable 96O..H and a random variable r G .. n, and use the random vari- 
able in a case-statement's branch conditions. Variable q is calculated once at the 
beginning of the simulation, but a new random variable r is calculated at each 
state-machine evaluation. The event g 1— > a in Event-B terms is implemented as 
a branch jAr = gn>aina case-statement. 

We now suggest how we may generate, and use the variables q and r in simu- 
lation. This aspect is work in progress, but we believe the approach will be useful 
for generating test scenarios, and therefore will help to improve test coverage. 
By adding a guard to the branch condition wc can influence the path taken 
through the code during simulation. In effect, wc reduce the non-dctcrminism in 
the state-machines, which allows us to guide the simulation, and therefore the 
exploration of the state-space. 

One question is, how to choose a value of n? We could base it on the total 
number of outgoing transitions of the state involved, but this would not give a 
large enough value. A typical state may have four transitions, plus a do-nothing 
transition, so a random number r G . . 4 could be used. However, we wish to 
manipulate the probability of a branch being taken, so that a branch is very 
unlikely to be taken; therefore, a much larger value for n is required. So, we 
calculate n based on the number of tests that would be required, for test coverage 
of all transitions, in all states. Likewise, the value of q must be unique within 
the case-statement; we just allocate an arbitrary, but unique value, close to n. 
In future work we will investigate how we could modify n during simulation 
runs, and use this value to reduce the probability of a simulation traversing 
previously explored state. In the code fragment below, we add the probabilistic 
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Fig. 5. Controlling the Simulation 



condition to the branch of the case-statement, where r = StartStopOlbjrandom 
(StartStopOlbjrandom is a random variable in the implementation code) and 
q = 3990. 

case EngMode is 

when ENG.STOPPING => 

if ((ENG.EngineSpeed = 0)) and (StopStartO lb .random = 3990) then 
EngMode := ENG-OFF; . . . 

Adding the branch condition gives us control over the likelihood that a partic- 
ular transition from a state will be taken when the state-machine is evaluated. 
We manually modify the conditions, to affect the behaviour of the simulation. 
We may wish to focus on exploring the state in a particular region. For instance, 
to test an engine-stop scenario, we require that the engine is in the ENG_ RUN- 
NING state, the gear is in NEUTRAL, the clutch is in the RELEASED state, 
and the steering NOTJJSED. Fig. [5] shows that we want large probabilities of 
transitions leading to the states that we want, and small ones departing. 

For a given simulation run we can define attracting and repelling states. 
Here, ENGTiUNNING is an attracting state; that is, we want the state-machine 
to be in that state or moving towards it most of the time. To achieve this we can 
adjust the branch conditions, to increase the probability of the transitions that 
lead to that state, being taken. For instance to increase the probability of the 
engine going from ENG.OFF to ENG.CRANKING we can modify the statement 
to read (StopStart01b_random <= 3990). In addition to this, we propose to 
record the navigated transitions, for transition coverage analysis. So, we will be 
able to use the data also, to guide the simulation. We show two simulation runs 
here, with the text output defined in the Task Body, Runl uses the 'unmodified', 
generated code; it simply loops and never reaches the ENG_RUNNING state. 
With the branch conditions modified, as described, Run 2 shows the simulation 
cycling from ENG-RUNNING to ENG-OFF; and with the indicator lamp 
changing to inform the driver of the situation. 



Run 2 



Run 1 

.ENG_Start_Order FALSE 
..ENG_Stop_Order FALSE 
...EngMode ENG.OFF 
....SSE Lamp OFF ... 



.ENG_Start_Order FALSE 
,.ENG_Stop_Order TRUE 
..EngMode ENG -RUNNING 
...SSE Lamp OFF 
ENG_Start_Order FALSE 
,.ENG_Stop_Order TRUE 
...EngMode ENG_STOPPING 
...SSE Lamp ORANGEJ3TOP 
ENG-Start„Order FALSE 
,.ENG_Stop_Order TRUE 
...EngMode ENG_OFF . . . 



5 Conclusions 

We have shown how we generate Ada code from State-machines, and illustrated 
the approach with a case study based on an automotive engine controller, auto- 
matic stop-start system. We describe how we simulate the environment, and a 
multi-tasking implementation. We gain an insight into how we adjust the con- 
ditions to provide meaningful simulation runs, which should be useful in the 
ADVANCE project. In future work we intend to record the transition coverage, 
and feed this back to the simulator, to ensure all transitions are covered. We 
will also investigate the interaction between the generated code, environment 
simulations, and ProB. 
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